REMARKS 



Upon entry of this Amendment, claims 1 through 20 are pending. Claims 1 through 20 
stand rejected under 35 U.S. C. §101 as not providing a useful, concrete, tangible result. Claims 
1 through 4 stand rejected for lack of novelty under 25 U.S.C. 102(e) in view of US Patent Appl 
2003/0088536 to Behnia. Claims 5 and 7 through 20 stand rejected for lack of novelty under 35 
U.S.C. 102(e) in view of US Patent Appl. 2004/0174392 to Bjoernsen. Claim 6 stands rejected 
as obvious in view of Bjoernsen and US Patent 7,039,596 to Lu. No new matter is submitted in 
the amendments to the claims. 

Claims 1, 5, 6, 7, 9, 13, and 18 are independent. 

The amended claims traverse rejection for lack of novelty and obviousness in light of all 
art of record. 

Rejection under $101 

The amended claims each recite a useful, concrete, tangible result. In State Street, cited 
by the Examiner, a datum corresponding to "price" was determined to meet the useful, concrete, 
and tangible result criteria facilitating trading in the real world. In the present case, inter alia, 
data of an affiliation meets the useful, concrete, and tangible result criteria because, for example, 
after presentation as recited in the claims, the user is able to take appropriate action in the real 
world such as performing a task, attending a meeting, or exchanging information with another 
person. 

Rejections under $102 and §103 

The Examiner has taken the position that Behnia teaches every limitation of independent 
claim 1. The Examiner has also taken the position that Bjoernsen teaches every limitation of 
independent claims 5, 7, 9, 13, and 18. Further, the Examiner has taken the position that 
Bjoernsen teaches every limitation of claim 6 except "the second multiplicity includes at least 
one field value of the first multiplicity and at least one field value not of the first multiplicity". 
Lu is cited to supply that limitation. 
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As discussed below, because all of the independent claims recite at least one limitation 
not found in any of Behnia, Bjoernsen, nor Lu, a prima facie case has not been made for lack of 
novelty nor obviousness. Withdrawal of the rejections is respectfully requested. 

Applicant has coined the word 'affiliation 5 to have a meaning for information processing 
as discussed in the originally filed specification, drawing, and claims. An affiliation as recited in 
the claims refers to information organized for use in an information system. Such information 
describes relations between persons herein called affiliates (e.g., see, Specification para. [0024]). 
In one embodiment, such information includes the data and relations portrayed in FIG. 4 together 
with Table 1. Practice of the embodiment of FIG. 4 and Table 1 is disclosed by Applicant in 
terms of a conventional database manager process that manipulates tables having records, 
records having fields, and fields having particular values. Other embodiments are discussed 
elsewhere in the Specification. 

To find an affiliation manager or an equivalent in a reference, the Examiner must at least 
find a unit of information corresponding to an affiliation; and find a process that manages a 
plurality of affiliations. Claims 1, 5, 6, 7, 9, and 13 recite an "identified affiliation" indicating 
that the unit of information corresponding to an affiliation must have an identifier. 

Turning to the specification, Applicant has distinguished an affiliation from other units of 
information in singular and in plural. Here are a few representative examples of the conceptual 
difference between an affiliation and units of information that may be found in the references of 
record. An affiliation is not merely a person, or merely a location, or merely a resource, or 
merely an item (appointment or task), or merely a project, or merely an account, or merely a 
disbursement, or merely an extract, or merely a folder, or merely a subject, or merely a note. 
Because a plurality of any one of these does not make an affiliation, an affiliation is not merely a 
contact list, or merely a map, or merely a list of resources, or merely a task list, or merely an 
appointment calendar, or merely a hierarchy of projects, or merely a system of accounts, or 
merely a schedule of disbursements, or merely a set of extracts, or merely a system of folders, or 
merely a dictionary of subjects, or merely a pad of notes. 

In the claims, the information units described for persons, items, and sessions are 
distinguished from an information unit called an "identified affiliation". Consequently, finding 
corresponding teachings for persons, items, and sessions, does not meet the limitation of 
"identified affiliation". 
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Behnia describes "knowledge objects" as "an object [is] a self-contained piece of 
software having data and procedures" (para. [0015]). Behnia describes classes as a hierarchical 
organization of objects (para. [0023]). The parent-child relationships in the hierarchy are 
generally determined during the design phase, (para. [96]). The hierarchy of Behnia is generally 
one to many. The primary hierarchy is account-policy-claim, (para. [0080]). And below claim 
is "project". The only relationships between persons are described as relationships between 
"contacts" within a "project" (para. [0244-0253]). Users are assigned to projects (para. [0235]). 
There is nothing in Behnia that has the function nor structure of an "identified affiliation", as 
claimed. 

The Examiner has mischaracterized a "project" of Behnia as teaching an affiliation as 
claimed. Assuming solely for the sake of this argument that a project of Behnia has structures 
and functions of a project disclosed by Applicant, an affiliation as described by Applicant may 
refer to or include one or more projects. Consequently, an affiliation provides different structure 
and function than an object of the project class taught by Behnia, 

One of the results provided by an affiliation manager is reduced risk of conflicts arising 
from physical limitations (e.g., time and place) and limitations on resources (e.g., expense 
budgets) (see Specification para. [0025]). 

Applicant has coined the word 'item 5 to have a meaning for information processing as 
discussed in the originally filed specification, drawing, and claims. An item as recited in the 
claims refers to information organized for use in an information system. Such information 
describes a task or appointment and related information affecting risk of various conflicts 
(Specification para. [0026, 0046, 0047]). In one embodiment, such information includes the data 
and relations portrayed in FIG. 7 together with Table 1. Practice of the embodiment of FIG. 7 
and Table 1 is disclosed by Applicant in terms of a conventional database manager process that 
manipulates tables having records, records having fields, and fields having particular values. 
Other embodiments are discussed elsewhere in the Specification. 

To find an affiliation manager or an equivalent in a reference, the Examiner must at least 
find a unit of information corresponding to an item; and find a process that manages a plurality 
of items. Claims 1, 5, 6, 7, 9, and 13 recite a "plurality of records wherein each record ... 
describes a respective item". Claim 18 recites, "a list of items". 
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Turning to the specification, Applicant has distinguished an item from other units of 
information in singular and in plural. Here are a few representative examples of the conceptual 
difference between an item and units of information that may be found in the references of 
record. An item is not a person, or a location, or a resource, or a project, or an account, or a 
disbursement, or an extract, or a folder, or a subject, or a note. Because a plurality of any one of 
these does not make an item, an item is not a contact list, or a map, or a list of resources, or a 
task list, or an appointment calendar, or a hierarchy of projects, or a system of accounts, or a 
schedule of disbursements, or a set of extracts, or a system of folders, or a dictionary of subjects, 
or a pad of notes. 

In the claims, the information units described for persons, sessions, and affiliations are 
distinguished from an information unit called an "item". Consequently, finding corresponding 
teachings for persons, sessions, and affiliations, does not meet the limitation of "item". 

The Examiner has mischaracterized various descriptions in Bjoernsen as teaching an item 
as claimed. In Bjoernsen a room may include facilities for collaboration named for a project 
(e.g., Development Turbine Z40 of FIG. 12); however, there is no mention of the collection of 
costs for a project. In Bjoernsen, there is no plurality of units of information corresponding to 
items as claimed. The only mention of cost is insufficient, to wit, in para. [0036] where "the cost 
of the [collaboration] session may be assigned to a particular user". Other costs are not 
accounted for. 

Lu does not supply a teaching of "affiliation" or "item". 

There is no suggestion to combine the teachings of Behnia, Bjoernsen, and Lu. 

Conclusion 

An extension of time believed to be 2 months is respectfully requested. Fees for the 
extension of time for a small entity (believed to be $225) are submitted herewith. 

Reconsideration is respectfully requested. Applicant believes the case is in condition for 
allowance and respectfully requests withdrawal of the rejections and allowance of the pending 
claims. 

The Examiner is invited to telephone the undersigned at the telephone number listed 
below if it would in any way advance prosecution of this case. 

Please revise the correspondence address to the new address shown below. 
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Respectfully submitted, 



Date: ^ S X<W AjJL^. - ^ 

William R. Bachand 
Reg. No. 34,980 

Bachand Law Office 
P.O. Box 54244 
Phoenix, AZ 85050 
(602) 326-6237 
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